1. Technical Field
The invention relates to accessing and organizing information in an electronic database in a computer environment. More particularly, the invention relates to the organization of data into a table-driven relational database system combining both relationship-based values and inherited attribute values in a computer environment.
2. Description of the Prior Art
E-commerce, as well as other business areas, requires different program operations based on factors such as who the buyer is, what it is that he is buying, and where he is shipping it to. Customarily, these information are hard coded at a given installation, where it is fairly easy to write the logic in normal software (e.g., C++). The problem is that the result is not easily configurable for other situations.
The challenge, especially in a buying system, is identifying not only who the person is, for example in a consumer Web site, but what department the person is in, what division the department is in, and what subsidiary the division is in. There is an hierarchical organizational structure involved.
Products have an hierarchy themselves. For example, light bulbs may be part of electrical items which may be part of durable goods.
Administrators frequently want to manage operations based on the hierarchical structure involved. For example, when a certain division buys durable goods, then a particular shipping method is chosen by default. This means that there are associated parameters that must be configured based on some arbitrary hierarchy, such as user groups, product groups, and promotional items.
A product could be: Christmas light bulbs go on sale December 26, otherwise they obey the rules of the durable goods, electrical supplies, light bulbs hierarchy. This is a multiple inheritance scenario. A product inherits attributes based on its structural organization—where it is in some classification system—but it is also based on arbitrary groupings that the vendor may make up.
Another problem that arises is that shipping methods and any choices presented to the user, are based on the relationship between two or more objects, each of which is playing a role, typically in the context of a transaction. For example, if the system is trying to find a shipping method, some typical roles would be: who the buyer is; what the product is; where it is being shipped from; and where it is being shipped to. The buyer may be identified based on when the role was set up for the division. However, it is undesirable to have the system figure out at runtime, i.e. when the query is being made, what every combination is for that buyer.
Three current approaches are property tables, attribute tables and access control lists:
Property Tables
Some applications maintain one or more “property tables” that can associate name value pairs with objects such as Users and Products. Property values are typically strings or string arrays, but more sophisticated implementation also support numbers or dates in a native fashion. The set of properties that can be stored in a property table is unconstrained. It does not have to be determined or anticipated by the application designers. Property tables only store values for objects, not relationships.
Relationship Tables
Some applications maintain one or more “relationship tables” to establish a relationship between two or more objects. Besides describing the relationship between objects, a relationship table can store some information about that relationship. For example, a single line on a purchase requisition may be said to be a relationship between a person and a product, with information such as the quantity ordered as attributes of that relationship. This is a two-way relationship.
The shipping charge for that line item can be based on the shipping origin, the destination and the product. This an example of a three-way relationship. Obviously the number of combinations can grow very large.
Typically the set of properties stored in a relationship table must be determined in advance by a database designer. Hierarchies are not addressed.
Access Control Lists
While ACL wasn't designed for generalized name:value storage, internally its structure is very much the same if privileges can be thought of as attribute names. ACL provides no equivalent of an attribute value, only the presence or absence of the attribute (a.k.a. privilege). ACL provides privileges between “member” groups and “resource” groups.
The problems with the current approaches are the following:    Lack of support for relationship-based values: Properties are owned by objects, not by the relationship between objects, therefore one can't set different values based on the parties in the relationship.    Lack of support for inherited values: Netscape Communication Corp.'s CommerceXpert requires the ability to group users and resources, and to support hierarchies of these groups. Examples include hierarchical user groups, org charts, catalog nodes, product groups and resource groups. Note that inheritance is needed on all ends of the relationship-based attribute value.    Native data types: Most property tables do not support native data types, preventing the database from efficiently recognizing that 500 is less than 1000 in a sort operation.    Extensible attributes: Most mechanisms make it difficult to define new attributes. In most cases a schema change is required to add attributes. Schema changes are not normally performed on running systems.    Flexible relationships: Few relational mechanisms allow for an arbitrary number of participants in a relationship.
It would be advantageous to provide a relationship-based inherited attributes system that gives the system administrator the ability to write determinative business or access rules using configurable parameters. It would further be advantageous to provide a relationship-based inherited attributes system that is user configurable, where the user can dynamically define what attributes and roles are involved.